home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9804 / 000113_owner-linux-arm…r.rutgers.edu _Tue Apr 21 06:28:49 1998.msg < prev    next >
Internet Message Format  |  1998-05-13  |  3KB

  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from orava.funet.fi (orava.funet.fi [128.214.248.46])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id GAA22176
  4.     for <willy@odie.fluff.org>; Tue, 21 Apr 1998 06:28:48 +0100
  5. Received: from vger.rutgers.edu ([128.6.190.2]:15942 "EHLO vger.rutgers.edu" ident: "root") by orava.funet.fi with ESMTP id <392661-15032>; Tue, 21 Apr 1998 08:25:17 +0300
  6. Received: by vger.rutgers.edu id <971096-319>; Tue, 21 Apr 1998 00:52:51 -0400
  7. Received: from odie.barnet.ac.uk ([194.82.202.98]:23115 "EHLO odie.barnet.ac.uk" ident: "willy") by vger.rutgers.edu with ESMTP id <971093-319>; Tue, 21 Apr 1998 00:16:51 -0400
  8. Received: (from willy@localhost)
  9.     by odie.barnet.ac.uk (8.8.6/8.8.6) id FAA21878;
  10.     Tue, 21 Apr 1998 05:23:36 +0100
  11. From: Matthew Wilcox <willy@odie.barnet.ac.uk>
  12. Message-Id: <199804210423.FAA21878@odie.barnet.ac.uk>
  13. Subject: Re: fd0* device for ADFS shape discs under i386 Linux
  14. To: alan@cymru.net (Alan Cox)
  15. Date:     Tue, 21 Apr 1998 05:23:35 +0100 (BST)
  16. Cc: ajb85@cam.ac.uk, linux-arm@vger.rutgers.edu
  17. In-Reply-To: <199804172058.VAA08472@snowcrash.cymru.net> from "Alan Cox" at Apr 17, 98 09:58:05 pm
  18. X-Mailer: ELM [version 2.4 PL25]
  19. MIME-Version: 1.0
  20. Content-Type: text/plain; charset=US-ASCII
  21. Content-Transfer-Encoding: 7bit
  22. X-Orcpt: rfc822;linux-arm@vger.rutgers.edu
  23. Sender: owner-linux-arm@vger.rutgers.edu
  24. Precedence: bulk
  25. X-Loop: majordomo@vger.rutgers.edu
  26. Status: RO
  27.  
  28. Alan Cox
  29. > > Someone should look at other filing systems to see how they cope with
  30. > > filesystems that don't provide nice inodes.  When Dickon Hood & I were
  31. > > experimenting with NFS servers under RISC OS, we had a structure that
  32. > > worked well; it was a tree, and the inode we returned was the address
  33. > > within that list.  You've got me intrigued now, I might just do it.
  34. > Several schemes are used. One of the cleanest if you stick to 2.1.8x+
  35. > is to issue inode numbers as you put things in the dcache and revoke
  36. > them as your inode is flushed. All open file inodes are in the dcache.
  37.  
  38. I don't have a problem with something being only valid for 2.1.8x+ linux,
  39. after all 2.2 will be soon enough.  However, would this scheme not screw
  40. NFS rather badly?  I thought inodes had to persist for the lifetime of the
  41. file.  NFS has the rather nasty requirement of having to preserve them
  42. over reboots.  [I've implemented an NFS server for RISC OS.  It is nasty.
  43. You may see it released rsn if certain other things happen.]
  44.  
  45. -- 
  46. Set Alias$Case Set Alias$[ |||| |MSet Alias$Otherwise Set Alias$[ \ Matthew
  47. "" |MSet Alias$When If %0=%%0 Then Set Alias$[ "" ||MIf %0=%%0    \ Wilcox
  48. Then Set Alias$Otherwise Set Alias$[ |||||||||||||||| ||MIf       \
  49. %0=%%0 Then Set Alias$When Set Alias$[ ||||||||||||||||
  50. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu